Computing devices, such as computers, mobile phones, tablet devices, digital cameras, multimedia devices, printers, and many other types of wired and wireless devices likely include a wireless communication device, such as for Wi-Fi data communication. The computing devices are generally integrated with Wi-Fi chips of the wireless communication device, and in conventional designs, the software that manages and controls the Wi-Fi wireless device includes a host device driver that executes on a host central processing unit (CPU) of the computing device (e.g., the main CPU of a mobile phone), and includes firmware that executes on the wireless communication device side (e.g., on the Wi-Fi chip). In the computing device, the host device driver and the firmware communicate with each other via one or more data buses, such as a secure digital input output (SDIO), a universal serial bus (USB), a peripheral component interconnect express (PCIE) bus, and the like.
Generally, data traffic is exchanged between the host device driver on the mobile phone and the wireless device firmware via a data bus. The data traffic includes control messages, such as commands, command responses, and events. For example, a command may be communicated from the host device driver to the wireless device firmware via the data bus, such as to direct an operation of the wireless device. A command response is then communicated back from the wireless device to the host device driver as an acknowledgement of the command. The wireless device firmware can also initiate an event control message to report a situation or status of the wireless device to the host device driver.
The wireless device firmware may develop a bug or become inoperable, which can stall or delay the control messages between the host device driver and the wireless device firmware. For example, the host device driver may initiate a command to the wireless device via the data bus, but not receive a response as an acknowledgement of the command from the host device driver. When the wireless device firmware becomes inoperable, the firmware needs to be debugged. However, in commercial implementations (e.g., in a mobile phone or tablet device that is in use by a consumer), Wi-Fi firmware debugging is not available, such as by “printing” run-time logs of the wireless device firmware, neither to a serial port which is too time consuming, nor to external non-volatile storage which is costly.
In development, the Wi-Fi firmware can be connected via a Joint Test Action Group (JTAG) interface to determine run-time status and errors. However, JTAG is generally only available as a port on development boards, rather than in the commercial implementations, such as in a consumer mobile phone or tablet device. In a consumer device, a conventional technique to debug the wireless device firmware is to analyze the data logs from the host device driver side. However this may only provide some indirect information about the wireless device firmware before the firmware fails, but does not provide insight as to what caused the wireless device firmware to stall or become inoperable.